Communication method and terminal between two units

ABSTRACT

Method of communication between a first unit and a second unit via a telecommunications network, the first unit comprising applications belonging respectively to a first family and a second family having a priori a lower degree of confidence than the first family, comprising the step of forcing at least one request originating from an application of the second family, transmitted over the network to the second unit, to include a mark associated with the second family of applications.

The present invention relates to computer terminals allowing networkbrowser-type activities and offering the users the possibility ofinstalling applications.

Such terminals may in particular be telephones using the wirelessapplication protocol (WAP), office computers, portable computers orpersonal digital assistants (PDA). They share the common characteristicof being connected to a digital data network which, in many practicalcases, is a network operating according to the IP protocol (“internetprotocol”), in particular the Internet.

In the case of a “closed” terminal (for example a Minitel), theapplications present on the terminal are known and cannot be changedduring the lifetime of the terminal.

The openness of a terminal refers to the facility offered to the user toinstall, and often download, new applications which are intended to berun by the terminal itself. Examples of “open” terminals which integratethis facility are:

-   -   application-downloading telephones, for example of the Java MIDP        type (“Mobile Information Device Profile”, Sun Microsystems,        Inc.);    -   browsers with scripting functionalities, for example of the        WMLScript type (see “WAP WMLScript Language Specification”,        version 1.1, WAP Forum, November 2001) or of the ECMAScript type        (also referred to as JavaScript, see “ECMAScript Language        Specification”, Standard ECMA-262, 3rd edition, December 1999),        or browsers which accept applets;    -   most PDAs, operating under operating systems such as PalmOS,        WindowsCE, Symbian etc.;    -   office or portable computers.

“Semi-open” terminals are open terminals in which certainfunctionalities are not directly accessible to the applicationsinstalled by the user or downloaded. For example, in a terminal whoseonly “openness” is ECMAScript, downloaded applications cannot access allthe functionalities of the network (for example, sending IP packets thatdo not comply with the formats of the most common transport protocols,that is TCP (“transmission control protocol”) or UDP (“user datagramprotocol”). These functionalities may be accessible in an indirect andcontrolled manner. For example, an ECMAScript function may order theloading of a page via HTTP (“hypertext transfer protocol”)), which usesthe network but in a controlled manner.

In “semi-open” terminals, the following coexist:

-   -   applications regarded as “confidence” applications, for example        because they have been factory-installed by the terminal        manufacturer, or because of the guarantee obtained by means such        as the electronic signature of the application, etc.;    -   and other applications which may be installed on the terminal by        the user himself, at his own discretion, but which do not access        the same rights as the confidence applications.

On the other hand, “fully open” terminals are open terminals in whichall functionalities are accessible to the downloaded applications. Theconcept of openness of a terminal depends largely on the context inwhich it occurs. For example, different layers of the OSI model(link/network/session/transport/etc.) may have different degrees ofopenness.

Interest is focused here on the functionalities which can be observedremotely from a server, that is to say network functionalities. In thiscontext, the “semi-open” character of a terminal generally implies thatexecution rights which can be observed remotely and which are accessibleto confidence applications are not accessible to non-confidenceapplications (for example, the right to transmit requests other thanHTTP on an IP network). This allows a server to distinguish, from amongthe requests received by it, those which originate from confidenceapplications and whose which originate from other applications. It mayin particular distinguish the requests originating from downloadedapplications from requests originating from applications present fromthe start in the terminal.

In open terminals, the possibility that a program may behave in adeceptive manner vis-à-vis the user (Trojan horse) must be taken intoaccount. Thus, nothing can guarantee to a server that a request actuallyoriginates from the user and not from a program which has simulated theuser's consent in the network. This risk undermines the confidence whichthe server may have in the data which it receives from a client. Theassumption that the requests addressed to the server reflect the actionsof the user is not reasonable if a Trojan horse has the facility to sendthem instead of the user.

A distinction will therefore be made hereinafter between theapplications present on the terminal:

-   -   confidence applications: the server is ready to make the        assumption that these applications are not Trojan horses. For        example, the WAP browser of a WAP telephone may constitute a        confidence application. Another example may be a Java MIDP        application downloaded with signature;    -   non-confidence applications: the server considers that these        applications may be Trojan horses. For example, Java MIDP        applications downloaded without signature on a terminal may be        non-confidence applications.

The conventional response to the Trojan horse risk is to limit thecapabilities of the non-confidence applications.

The limitation of the transmission of frames from semi-open terminals isnormally imposed in an extremely strict manner. Only system applications(supplied with the terminal's operating system) are authorized totransmit certain frames.

It therefore becomes impossible for a downloaded application (with orwithout confidence) to transmit frames to a server, even if thatapplication has means from another source of obtaining the confidence ofthe server due to the content of the frames that this applicationtransmits (for example: transmitting signed data) or due tocharacteristics of the application (for example: signature associatedwith its content).

One object of the present invention is to offer a difference ofcapability to send requests of a new type between “confidence”applications and “non-confidence” applications that is flexible for theapplications and can nevertheless be identified by the receiving server.The concept of confidence may rely on varied criteria (signature, typeof interchange, URL from which the application has been downloaded,etc.).

The invention thus proposes a method of communication between a firstunit and a second unit via a telecommunications network in which thefirst unit comprises applications belonging respectively to a firstfamily and a second family having a priori a lower degree of confidencethan the first family. According to one aspect of the invention, eachrequest originating from an application of the second family,transmitted over the network to the second unit, is forced to include amark associated with the second family of applications. According toanother aspect of the invention, each request originating from anapplication of the second family, transmitted over the network to thesecond unit, is forced to exclude a mark associated with the firstfamily, the said mark being included in at least some of the requeststransmitted over the network and originating from applications of thefirst family. The invention also proposes a communication terminal,comprising means of using such a method as a first unit.

The method allows certain particular (“confidence”) applications runningin the first unit to transmit frames for the attention of a second unit,usually a remote server, with the guarantee for this second unit of thereliable origin of these frames. The mandatory inclusion of the mark forthe a priori non-confidence applications of the second family (orsymmetrically its barring) distinguishes, in transmission, the framestransmitted by these a priori non-confidence applications from thosetransmitted by confidence applications. This allows the server to sortbetween acceptable requests, in which it has confidence, and those thatit must reject.

The applied mark must be completely “watertight”, that is to say it mustnot be possible for an a priori non-confidence application toshort-circuit the checks made at a certain level (for example: HTTPrequest functions), by attacking the lowest layers (for example: TCPconnection request).

In one embodiment of the method, the mark, included in a requesttransmitted over the network and originating from an application of thesecond family is forced to include an indication of the nature and/ororigin of the said application of the second family. This indicationconsists for example in data relating to the certification of thesignature of a signed application, or else to the download address of anapplication downloaded via the network. It may be used by the remoteunit to assess whether it may have confidence in the application which apriori could be considered only to be a non-confidence application bythe first unit.

Thanks to the method, terminals supporting the downloading ofapplications may interchange data in full confidence with a server,despite the risks inherent in these download capabilities (“openness” ofthe terminal). The method thus provides a simple and effectiveprotection against Trojan horses.

Other features and advantages of the present invention will appear inthe following description of non-limiting exemplary embodiments, withreference to the appended drawing, in which the single FIGURE is aschematic of a system using the invention.

An attempt is made to allow a remote unit such as a server 1 to obtainin a secure and flexible manner the confidence in requests received overa telecommunications network R from a semi-open terminal 2. Thisterminal hosts on the one hand confidence applications 3, such as forexample a web browser, and on the other hand a priori non-confidenceapplications 4, particularly applications that the terminal user hasdownloaded via the network R.

The a priori non-confidence applications 4 are constrained as to theframes or requests that they may transmit over the network R, which, inthe schematic, is symbolized by a control layer 5 forming part of theresources 6 for access to the network with which the terminal 2 isequipped.

The control layer 5 verifies that certain properties are fulfilled bythe frames transmitted by the a priori non-confidence applications 4. Ifthese properties are fulfilled, the control layer allows the frames topass. Otherwise, it can either not let them pass to the network R andnotify thereof the application 4 that has transmitted them, or modifythe frames to make them conform to the requirements of the a priorinon-confidence applications. In the latter case, the frame loses itscredibility in the eyes of the server 1 which will not be able toexploit it.

The aforementioned constraints relate to the presence or absence of aspecific mark in the requests transmitted over the network R fromcertain applications.

In a first embodiment of the invention, the control layer 5 forces therequests originating from a priori non-confidence applications 4 toinclude a mark associated with this family of applications. A confidenceapplication 3 gains access to functionalities which allow it to bypassthe control layer 5 and transmit unmarked requests. On the other hand,the resources 6 for access to the network do not place thesefunctionalities at the disposal of the a priori non-confidenceapplications 4.

In an example illustrating this first embodiment, the terminal 2 (forexample a mobile telephone) has a Java virtual machine that maycorrespond to the module 6 in the FIGURE. The virtual machine can beused to run downloaded applications written in the Java programminglanguage produced by Sun Microsystems, Inc. All the Java languageinstructions are executed by the virtual machine, which calls the systemfunctions after a certain check. The Java applications are clearly in asemi-open environment because there is no unchecked call to the systemfunctions. This terminal 2 is capable of downloading only Java code, noother type of application being able to be installed thereon by theuser.

The a priori non-confidence application 4 is then written in Javalanguage.

In this example, the protocols brought into play for the interchanges ofthe terminal 2 over the network R are the HTTP protocols (RFC 1945(Request For Comments′), published in May 1996 by the IETF (“InternetEngineering Task Force”)), TCP (RFC 793, IETF, September 1981) and IP(RFC 791, IETF, September 1981).

The service is hosted by an HTTP server 1 which stores the contentbelonging to the user. It must satisfy itself of the fact that a request(requesting for example the deletion of all the files) effectively comesfrom the user, and not from a malicious Java program. This service is ofcourse an example, since any other service can use this technique(electronic commerce, document publication, messaging, etc.).

The mark may be included in the “user-agent” header field of the HTTPrequests (see section 10.15 of the aforementioned RFC 1945). It consistsin a specific string such as “Non-confidence application: VM Java 1.2”which indicates by its presence that the request does not originate froman a priori confidence application. This string may already be presentin the request produced by the application 4, in which case the controllayer 5 of the virtual machine 6 merely verifies its presence.Otherwise, this layer 5 inserts it so that the request is properlymarked.

The watertightness of the mark applied by the virtual machine 6 resultsfrom the fact that it is not possible for an a priori non-confidenceapplication 4 to transmit over the network R HTTP requests that do notcontain this specific string. In particular, the application 4 cannothave access to the network R by connecting to a protocol layer lowerthan HTTP, particularly to the TCP sockets. The mark is implementeddirectly in the virtual machine 6 in which the a priori non-confidenceapplication is obliged to run and which it can in no manner avoid.

The server 1 may thus sort, from among the requests that it receives,those that originate from a priori non-confidence applications 4 andthose that originate from confidence applications 3 such as a webbrowser.

There are applications that are confidence applications for certainsites only. For example, a Java applet is usually considered to be aconfidence applet by the site from which it has been downloaded, but notby other sites. The mark will therefore not always be necessary in therequests sent to this download site. In other words, the virtual machine6 may impose a mark on requests originating from such an applet andtransmitted to a site other than that to which it has been downloadedand leave the applet free to include or exclude the mark in the requeststhat the applet transmits to its source site. Another possibility is toimpose the mark on any request transmitted by such an applet,irrespective of its destination.

An alternative or a supplement to the marking of non-confidence requestsmay be the barring of some of these requests. For example, fornon-confidence applications downloaded from a given server, requestsdirect to different servers may be barred. Requests to the source serverwould remain possible, with the mark.

In an advantageous embodiment, the mark has to be supplemented by anindication of the nature and/or origin of the a priori non-confidenceapplication 4 from which it has originated.

This a priori non-confidence application 4 may be signed. The requeststhat originate therefrom will then be marked with a header containing atleast one of the following elements likely to establish the remoteserver's confidence in this application:

-   -   the application's signatory's certificate, or a digest of that        certificate;    -   the certificate of the certification chain from where the        application's signatory's certificate originated, or a digest of        that certificate;    -   a string specially included in the code of the application for        this purpose;    -   a variable element identifying the application in a dynamic        manner.

Such an embodiment of the invention is particularly applicable in thecase of a Java application signed by a certificate.

In this case, the virtual machine 6 must verify the signature of theJava application before the transmission of the requests. In practice,this verification takes place before the application 4 is run.

The mark may then consist in the addition of a specific string in theHTTP header, such as for example: “Confidence content — Applicationsigned by <C>” where <C> is the value of the application's signatory'scertificate, or a digest of the latter. This header indicates by itspresence that the request comes directly from a user, and has beencreated by a software program of known provenance.

In this manner, if the server 1 places its confidence in the holder ofthe private keys associated with the certificate <C>, the server isassured that the requests marked in this specific header trulycorrespond to an effective consent of the user. The marking requirementmeans that the application cannot claim, to the server, the authority ofa signatory other than the real signatory.

In the case of downloaded Java applets, the virtual machine 6 is capableof identifying the download address of the application. It may thusforce the request originating from such an applet, an a priorinon-confidence request, to include its download address or data relatingto that address.

In another embodiment of the invention, the mark syntax is inverted: thecontrol layer 5 forces the requests originating from the a priorinon-confidence applications 4 to exclude a mark specific to theconfidence applications 3.

To manifest itself as being a confidence application for a server 1, anapplication 3 then includes the mark in the request that the application3 sends to the server 1. The control layer 5 ensures that this mark isabsent from each request originating from an a priori non-confidenceapplication 4, the non-confidence character being able, as previously,to be judged according to the destination site of the request. If themark is present in a request originating from an a priori non-confidenceapplication 4, the request is not transmitted as such: the mark isremoved by the control layer 5 and the latter may or may not transmitthe “demarked” request over the network R and may or may not notify theapplication 4.

The convention used for the mark syntax must naturally be common to theterminal and the server, and known to both before the transaction.

1. A method of communication between a first unit and a second unit viaa telecommunications network, in which the first unit comprisesapplications belonging respectively to a first family and a secondfamily having a priori a lower degree of confidence than the firstfamily, the method comprising: forcing at least one request originatingfrom an application of the second family, transmitted over the networkto the second unit, to include a mark associated with the second familyof applications.
 2. The method according to claim 1, wherein said markis included in at least one request transmitted over the network andoriginating from an application of the second family.
 3. The methodaccording to claim 1, wherein the mark, included in a requesttransmitted over the network and originating from an application of thesecond family, is forced to include an indication of the nature and/ororigin of the said application of the second family.
 4. The methodaccording to claim 3, wherein said application of the second familybeing signed, the mark included in the requests that originatedtherefrom is forced to include data relating to the certification of thesignature.
 5. The method according to claim 3, wherein the saidapplication of the second family having been downloaded via the networkfrom a download address, the mark included in the requests thatoriginated therefrom is forced to include data relating to the downloadaddress of the application.
 6. A method of communication between a firstunit and a second unit via a telecommunications network, in which thefirst unit comprises applications belonging respectively to a firstfamily and to a second family having a priori a lower degree ofconfidence than the first family, the method comprising: forcing atleast one request originating from an application of the second family,transmitted over the network to the second unit, to exclude a markassociated with the first family, the said mark being included in atleast some of the requests transmitted over the network and originatingfrom applications of the first family.
 7. The method according to claim6 wherein the second unit examines whether the mark is present in arequest received over the network from the first unit, to assess adegree of confidence to be attached to the said request.
 8. The methodaccording the claim 7, wherein, when the mark is present the saidrequest, the second unit also examines data included in this mark, toassess a degree of confidence to be attached to said request.
 9. Themethod according to claim 8, wherein said data examined by the secondunit comprises data relating to the certification of a signature of theapplication from which the request originated.
 10. The method accordingto claim 8, wherein said data examined by the second unit comprise datarelating to a download address of the application from which the requestoriginated.
 11. The method according to claim 6, wherein the requestscomprise HTTP requests, and the mark is inserted in the headers of theHTTP requests.
 12. The method according to any one of the precedingclaim 6, in which the requirement relating to the mark is controlled bya software layer belonging to a virtual machine with which the firstunit is provided, the applications of the second family being able toaccess the network only via the virtual machine and the said softwarelayer.
 13. The method according to claim 12, wherein the virtual machineis a Java virtual machine.
 14. A communication terminal, comprisingmeans for communicating with a second unit via telecommunicationsnetwork, the communication terminal further comprising applicationsbelonging respectively to a first family and a second family having apriori a lower degree of confidence than the first family, wherein themeans for communicating are adapted to force at least one requestoriginating from an application of the second family, transmitted overthe network to the second unit, to include a mark associated with thesecond family of applications.
 15. A communication terminal, comprisingmeans for communicating with a second unit via a telecommunicationsnetwork, the communication terminal further comprising applicationsbelonging respectively to a first family and a second family having apriori a lower degree of confidence than the first family, wherein themeans for communicating are adapted to force at least one requestoriginating from an application of the second family, transmitted overthe network to the second unit, to exclude a mark associated with thefirst family, the said mark being included in at least some of therequests transmitted over the network and originating from applicationsof the first family.
 16. The method according to claim 1, wherein eachrequest originating from an application of the second family,transmitted over the network to the second unit, is forced to include amark associated with the second family of applications.
 17. The methodaccording to claim 6, wherein each request originating from anapplication of the second family, transmitted over the network to thesecond unit, is forced to exclude a mark associated with the firstfamily.